-- card: 20129 from stack: in.0
-- bmap block id: 0
-- flags: 0000
-- background id: 3797
-- name: 


-- part contents for background part 1
----- text -----

From: howard@cpocd2.UUCP (Howard A. Landman)

Date: 28 Feb 88 22:45:26 GMT

I posted this bug before, but it was buried in the middle of a long posting,
and it's major, so I wanted to make sure it got seen.

BUG:
The HyperTalk command

read from file f until newline

doesn't work.  It reads past a newline and stops about 31 or 32 characters
into the file (in the case I tried).

REPEAT-BY:
Grab the Go games data I posted to rec.games.go a week or so ago, or create a
file which begins (each line below ends with a newline):
---->8 CUT HERE 8<------
Date: 1579? to 1587?
White: Honinbo Sansa
Black: Kashio Rigen
Score: +1
Komi: 0
Result: +1
Source: Go Review, Autumn 1973, p.54-61 

Date: 1585 to 1650 ??
White: Kuo Pai-ling
Black: Chou Lan-yu
Handicap: 2-2 (tasuki)
Score: -0.5 C
Komi: 0
Result: -0.5 C
Source: GW #28, Summer 1982, p.63-65 

---->8 CUT HERE 8<------
Then put that file on your Mac, go into HyperCard, and either type the
following commands into the message box or put them into a script (with
the obvious modifications):

open file "foo"
read from file "foo" until newline
it

What *I* got was:

"Date: 1579? to 1587?\nWhite: Hon"

where, in normal C notation, the \n represents a newline.  In HC this shows
up as a square (no bitmap for that character in the font).

I know that the end-of-line character is a newline, both because I have looked
at it in UNIX, and because the file was created *by* *HyperCard* with a
newline constant after each line.

WILD, WILD GUESS AS TO WHAT'S GOING ON:
If this portion of HyperCard was written in C, is it possible that someone
accidentally typed 'n' instead of '\n' at some point?  That would explain
why it stopped on an 'n'.  (That should be easy to test, but I'm not getting
paid to do this.)



-- part contents for background part 45
----- text -----
HyperCard bug